Те из вас, кто следят за ИТ-новостями, наверняка слышали о последних уязвимостях, обнаруженных в процессорах Intel. Одной из таких уязвимостей стала Spectre - она потенциально позволяет локальным приложениям (локальному атакующему, при запуске специальной программы) получить доступ к содержимому виртуальной памяти текущего приложения или других программ.

На днях компания VMware опубликовала обновления для своей платформы VMware vSphere, которые устраняют потенциальные проблемы со Spectre (сама уязвимость описана вот тут).

Исправления для серверов VMware vCenter можно скачать по этим ссылкам:

• VMware vCenter Server 5.5 Update 3g - Release Notes - Загрузить
• VMware vCenter Server 6.0 U3d - Release Notes - Загрузить
• VMware vCenter Server 6.5 U1e - Release Notes - Загрузить

Вы можете скачать как установочный образ:

так и патч к vCenter с VMware Patch Portal (ищите обновление от 9 января):

Для серверов VMware ESXi надо пойти на VMware Patch Portal и загрузить оттуда обновление ESXi650-201801401-BG / ESXi650-201801402-BG. (номер билда 7526125). Подробная информация об обновлении приведена в KB 2151099.

Также данное исправление доступно и для настольных платформ виртуализации VMware:

• VMware Workstation 14.1.1 Pro for Linux - Загрузить
• VMware Workstation 14.1.1 Pro for Windows - Загрузить
• VMware Fusion 10.1.1 (для Intel-based Macs) - Загрузить
• VMware Fusion 8.5.10 (для Mac OS X) - Загрузить

Спасибо нашему читателю Стасу за новость об этих исправлениях.

Гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего услуги аренды виртуальных машин.

Blockchain — это принципиально новая технология, которая в последнее время приковывает к себе все больше внимания. Специалисты из таких отраслей, как финансы, экономика, медицина, логистика, IoT, активно работают над исследовательскими и экспериментальными проектами с использованием блокчейн, поскольку эта технология заточена не только на криптовалюты.

Отметим, что Hyperledger Fabric — это не компания, не криптовалюта, а проект с открытым исходным кодом, организованный сообществом Linux Foundation, который был создан для продвижения блокчейн-технологии. Это нечто, похожее на хаб для открытой разработки отраслевых блокчейнов. Hyperledger Fabric дает широкие возможности, позволяя разработчикам сконцентрироваться на запуске блокчейн-проекта с собственной бизнес-логикой.

Взгляд изнутри

Суть утилиты Blockchain on vSphere заключается в возможности развернуть несколько узлов кластера Hyperledger Fabric, так называемых Pods, причем максимально просто. При этом в Blockchain-сервисе используются три учетные записи:

• Cloud Admin,
• Blockchain Admin,
• Blockchain Developer.

Каждая из них имеет соответствующие полномочия на разных уровнях системы: Cloud Admin может мониторить и работать с инфраструктурой на базе vSphere, Blockchain Admin — управлять платформой blockchain (Hyperledger Fabric), а разработчик Blockchain фокусируется на разработке приложений с использованием платформы blockchain.

Градация полномочий на разных уровнях системы

Hyperledger Fabric — это распределенная система, реализованная с использованием контейнеров. Она может быть развернута на платформе, которая поддерживает контейнерный стандарт OCI. При этом для управления контейнерами Fabric используется система Kubernetes. В основе рассматриваемого примера для Fabric v1.0 лежит следующая архитектура:

• Используются пространства имен для поддержки различных организаций Fabric.
• Используется настраиваемое количество одноранговых узлов в организации.
• Организуется изоляция через Persistent Volume.

Архитектура решения

Инструкция по развертыванию

Для реализации блокчейн-проекта с использованием Hyperledger Fabric необходимо выполнить ряд предварительных требований, включающих наличие: Читать статью далее->>

В декабре прошлого года мы писали о том, что компания VMware выпустила обновление ESXi 6.5 Update 1 Patch 2, а также вскользь упомянули апдейт сервера управления - VMware vCenter 6.5 Update 1d. А вчера в нашей заметке про обновленный vSphere Client наш читатель обратил внимание на статью в блоге VMware, где рассказано о некоторых новых фичах vSphere Client, версия 3.21 которого была включена в состав vCenter 6.5 Update 1d.

Как обычно обновился и документ о различиях vSphere Client и vSphere Web Client на момент 18 декабря прошлого года (то есть до версии vSphere Client 3.31).

Давайте посмотрим, что за фичи есть в HTML5-клиенте, который поставляется с vCenter 6.5 Update 1d, по сравнению с его прошлой версией, включенной в vCenter.

1. Улучшенный вид интерфейса Clarity.

Благодаря новому подходу VMware за счет фреймворка Clarity интерфейс клиента стал более эстетичным и удобным в использовании. Давайте взглянем, например, на возможность переключения между Active и Consumed Memory в vSphere Client:

2. Настройка vSphere Proactive HA.

Ранее это можно было делать только через Web Client, теперь это выглядит удобно и красиво:

3. Появилась настройка Content Library.

Важная фича - добавление уже существующей библиотеки с контентом (например, с другого сервера vCenter):

4. Настройка Network IO Control (NIOC) на VDS.

Теперь это возможно через vSphere Client (вместе с настройкой LAGs и LACP) для vSphere Distributed Switch (VDS), включая изменение параметров шлюза на адаптерах VMkernel:

5. Настройка политик хранения (Storage Policies).

Ранее это было доступно только через Web Client (например, нельзя было создать новую политику в HTML5-клиенте), но теперь можно делать все операции в удобном рабочем процессе для vSphere Client, который, кстати, был упрощен.

6. Управление VIB-пакетами.

Очень удобный раздел, чтобы узнать, какие дополнения в виде VIB-пакетов установлены на хосте ESXi. Доступно по адресу Host –> Configure –> System –> Packages:

7. Управление настройками ВМ и шаблонами.

Теперь в VM Settings можно настраивать все параметры виртуальных машин, включая добавление новых виртуальных устройств, таких как NVMe, SCSI, USB Controller и Host-based USB Adapter. Кроме того, появилась возможность работы с шаблонами (VM Templates).

8. Настройка VM Guest Customization Specifications.

При развертывании ВМ из шаблонов с помощью HTML5-клиента теперь можно использовать спецификацию созданную с помощью встроенного мастера, либо указать уже существующий файл спецификации.

Скачать текущую версию VMware vSphere Client можно по этой ссылке. VMware vCenter 6.5 Update 1d доступен тут.

Компания VMware в первые дни нового года выпустила очередное обновление своего HTML5-клиента для управления виртуальной инфраструктурой - VMware vSphere Client 3.32.

Напомним, что ранее мы писали о возможностях клиента 3.30 и ниже, поэтому приведем новые возможности версий vSphere Client 3.31 и 3.32, где, в основном, из нового - это управление объектами vApp:

• Операции включить/выключить/перезагрузить/приостановить для виртуальных сервисов (vApp) - это показано на рисунке выше.
• Переименование/удаление сервиса vApp.
• Экспорт объекта vApp в шаблон виртуального модуля OVF.
• Отоносящиеся к объектам vApp вкладки VM, datatastore и networking.
• Действие Add Permission для шаблонов ВМ (templates).
• Выбранные счетчики производительности в разделе Performance Charts сохраняются для данного пользователя в локальном хранилище его браузера. Это позволяет не настраивать их заново при открытии новой сессии клиента.
• Исправлены некоторые ошибки.

Скачать VMware vSphere Client можно по этой ссылке.

«Код безопасности» анонсировал выход продукта vGate 4.0. Решение для защиты виртуальных инфраструктур будет востребовано компаниями, применяющими виртуальные платформы VMware vSphere или Microsoft Hyper-V последних версий. Продукт позволяет настроить инфраструктуру согласно различным требованиям с помощью наборов политик, разграничить права доступа администраторов, а также обеспечить защиту от несанкционированного доступа к виртуализованным ресурсам.

Недавно компания Microsoft выпустила интересное сравнение стоимости владения онпремизной инфраструктурой VMware vSphere с облачной IaaS-инфраструктурой Microsoft Azure. Оформлено это сравнение в виде калькулятора совокупной стоимости владения (Total Cost of Ownership, TCO) - Azure TCO Calculator.

Результаты расчетов на Azure TCO Calculator показывают экономию на Azure в размере до 84% относительно аналогичной онпремизной инфраструктуры VMware (на отрезке в 3 года). Сотрудники VMware смотреть на такое спокойно не смогли и разразились гневным постом, где написали о том, что вот буквально недавно закончили Whitepaper, где многие опрошенные ИТ-компании говорят о том, что онпремизная инфраструктура обходится иногда дешевле облачной, а 65% говорит, что если и дешевле, то не более, чем на 10% (некоторые выводы суммаризованы вот тут).

Сотрудники VMware сетуют на следующие недочеты в подходе Microsoft к анализу TCO:

• Microsoft почему-то считает необходимым покупку лицензий vSphere каждый год при расчете 3-летней TCO.
• При расчете используется 500 ВМ с конфигурацией 2 vCPU / 4 ГБ, для которых требуется аж 1 984 ядра и 33 ТБ RAM. Это в 4 раза больше по CPU и в 16 раз больше по памяти чем требуется, считают в VMware.
• Для расчета Azure Pay-As-You-Go модели используются инстансы B-series, которые Microsoft рекомендует для небольших нагрузок (типа разработки/тестирования).
• Для расчета облачной нагрузки используется дефолтная цифра 40% в качестве времени работы серверов в течение месяца. Это неприменимо к продакшен серверам - они должны быть включены круглосуточно.
• Для расчета TCO VMware используются лицензии vSphere Enterprise Plus, которые существенно функциональнее текущих сервисов Azure. А вот функции Premium storage и Operations Management Suite в облаке будут стоить дополнительных денег (и тогда уже можно сравнивать с Enterprise Plus).
• По расчетам Microsoft, онпремизные серверы, хранилища и сети потребляют 20% от своей стоимости в год на обслуживание. VMware считает это дороговато.
• Microsoft не учитывает остаточную стоимость серверов и оборудования по прошествии трех лет расчета. Что надо бы учесть по мнению VMware.

На основе тезисов, приведенных выше, компания VMware добавила в сравнительную таблицу колонку "Calculator with corrections", которая отражает реальное по мнению VMware положение дел:

В качестве исходных данных здесь предполагается инфраструктура из 500 ВМ с конфигурацией 2 vCPU / 4 ГБ. Если считать, что для одной ВМ нужно 2 vCPU на одно физическое ядро, то понадобится всего 8 двухпроцессорных хостов (по 32 ядра на процессор в каждом). С точки зрения памяти, VMware считает, что будет достаточно 8 ТБ на 500 машин, что достаточно разумно (16 ГБ на машину с учетом техник оптимизации памяти - это в целом ок).

Согласитесь, что VMware считает деньги в данном случае совсем по-другому и очевидно, что с лукавством Microsoft в своем калькуляторе немного перегнула палку.

Или нет? Что вы думаете?

Компания VMware после очень долгого перерыва выпустила новую версию своего главного продукта для перенесения физических серверов в виртуальную среду - VMware vCenter Converter Standalone 6.2. Напомним, что прошлая версия этого средства вышла почти два года назад (мы писали о vCenter Converter Standalone 6.1 вот тут) - и никто не переживал по этому поводу.

Давайте посмотрим, что нового VMware добавила в Converter за прошедшие почти 2 года:

• Поддержка целевых хостов VMware vSphere 6.5 Update 1.
• Поддержка новых ОС физических серверов - Windows Server 2016 и Ubuntu 16.
• Новая конфигурация для миграции Linux-серверов. Теперь можно указать путь ко временным файлам vmware-sysinfo, которые будут распакованы и запущены.
• Новая опция, позволяющая изменить дефолтный тип диска целевой виртуальной машины с thick ("толстого") на thin ("тонкий"). Для этого нужно отредактировать файл converter-worker.xml.

Не так уж и много, да? Похоже, конвертером особо никто не занимался... Таким образом, список поддерживаемых конвертеров операционных систем выглядит так:

• Windows Vista SP2 до Windows 10
• Windows Server 2008 SP2 до Windows Server 2016
• CentOS 6.x and 7.0
• Red Hat Enterprise Linux 4.x up to 7.x
• SUSE Linux Enterprise Server 10.x and 11.x
• Ubuntu 12.04 LTS, 14.04 LTS, and 16.04 LTS

Офлайн конверсия машин с Microsoft Hyper-V может быть проведена для следующих ОС:

• Windows Server 2008 R2 (64-bit)
• Windows Server 2012 (64-bit)
• Windows Server 2012 R2 (64-bit)
• Windows 10 (64-bit)
• Windows Server 2016 (64-bit)

Более подробно о новой версии VMware vCenter Converter Standalone 6.2 написано в Release Notes, скачать продукт можно по этой ссылке.

Часто администраторы виртуальной инфраструктуры VMware vSphere испытывают необходимость увеличить размер виртуального диска VMDK, который защищен технологией репликации VMware vSphere Replication. Если попытаться увеличить диск из vSphere Client, то вы получите вот такую ошибку:

vSphere Replication does not support changing the length of a replicated disk

Поэтому для увеличения реплицируемого VMDK-диска нужно сделать следующее:

• Переименуйте папку с виртуальной машиной и виртуальным диском на резервном сайте. Это нужно для того, чтобы при отключении репликации папка с ВМ на резервной площадке не удалилась.
• Запомните настройки репликации ВМ (RPO, датастор назначения и т.п.).
• Отключите репликацию виртуальной машины.
• Увеличьте размер виртуального диска на основной площадке из GUI vSphere Web Client через Edit Settings.
• Теперь увеличьте размер виртуального диска на резервной площадке с помощью утилиты vmkfstools. Для этого выполните команду:

vmkfstools –X 50G virtual_machine.vmdk

• Далее на резервном сайте переименуйте папку с ВМ обратно к исходному имени.
• Настройте репликацию ВМ заново, выбрав пункт Specify datastore folder и указав папку с ВМ, которую будете реплицировать. Появится сообщение:

A file with the name ‘[<datastore>] <folder>/<filename> already exists. Press Yes to use file as an initial copy.

• Нажимайте Yes и репликация должна завестись.

Если вы не увеличите размер виртуального диска на резервной площадке, то получите вот такое сообщение об ошибке:

The capacity of the seed disk does not match the capacity of the replication source disk. Create a new seed copy or verify that you selected the correct seed to use for this replication

Поэтому не пропускайте этот шаг. Также о процедуре написано в KB 2052883.

Недавно мы писали о полезных утилитах командной строки виртуального модуля VMware vCenter Server Appliance (vCSA), которые могут пригодиться при ежедневном администрировании виртуальной инфраструктуры VMware vSphere. А сегодня поговорим о сервисах vCSA - как они запускаются, и как ими управлять.

Первичный порядок загрузки служб vCenter Server Appliance выглядит следующим образом (приведены в порядке запуска):

• lwsmd (Likewise Service Manager)
• vmafdd (VMware Authentication Framework)
• vmdird (VMware Directory Service)
• vmcad (VMware Certificate Service)
• vmware-sts-idmd (VMware Identity Management Service)
• vmware-stsd (VMware Security Token Service)
• vmdnsd (VMware Domain Name Service)
• vmware-psc-client (VMware Platform Services Controller Client)
• vmon (VMware Service Lifecycle Manager)

А где же такие службы, как vmware-vpostgres, vpxd и прочие? Все просто - их запускает служба vmon. Это новый watchdog-сервис, который управляет службами vCSA в vSphere 6.5 и унифицирует доступ к ним через API.

Чтобы увидеть, в каком порядке она запускает прочие сервисы, выполним команды vmon-cli для остановки и запуска служб vmon на сервере vCSA:

/usr/lib/vmware-vmon/vmon-cli --batchstop ALL 

/usr/lib/vmware-vmon/vmon-cli --batchstart ALL

Вывод будет примерно таким:

root@vc01 [ /var/log/vmware/vmon ]# grep "Executing op START on service" vmon-sys 

17-12-12T09:44:23.639142+00:00 notice vmon Executing op START on service eam... 

17-12-12T09:44:23.643113+00:00 notice vmon Executing op START on service cis-license... 

17-12-12T09:44:23.643619+00:00 notice vmon Executing op START on service rhttpproxy... 

17-12-12T09:44:23.644161+00:00 notice vmon Executing op START on service vmonapi... 

17-12-12T09:44:23.644704+00:00 notice vmon Executing op START on service statsmonitor... 

17-12-12T09:44:23.645413+00:00 notice vmon Executing op START on service applmgmt... 

17-12-12T09:44:26.076456+00:00 notice vmon Executing op START on service sca... 

17-12-12T09:44:26.139508+00:00 notice vmon Executing op START on service vsphere-client... 

17-12-12T09:44:26.199049+00:00 notice vmon Executing op START on service cm... 

17-12-12T09:44:26.199579+00:00 notice vmon Executing op START on service vsphere-ui... 

17-12-12T09:44:26.200095+00:00 notice vmon Executing op START on service vmware-vpostgres... 

17-12-12T09:45:33.427357+00:00 notice vmon Executing op START on service vpxd-svcs... 

17-12-12T09:45:33.431203+00:00 notice vmon Executing op START on service vapi-endpoint... 

17-12-12T09:46:54.874107+00:00 notice vmon Executing op START on service vpxd... 

17-12-12T09:47:28.148275+00:00 notice vmon Executing op START on service sps... 

17-12-12T09:47:28.169502+00:00 notice vmon Executing op START on service content-library... 

17-12-12T09:47:28.176130+00:00 notice vmon Executing op START on service vsm... 

17-12-12T09:47:28.195833+00:00 notice vmon Executing op START on service updatemgr... 

17-12-12T09:47:28.206981+00:00 notice vmon Executing op START on service pschealth... 

17-12-12T09:47:28.220975+00:00 notice vmon Executing op START on service vsan-health...

Как мы видим, службы запускаются в следующем порядке:

• eam (VMware ESX Agent Manager)
• cis-license (VMware License Service)
• rhttpproxy (VMware HTTP Reverse Proxy)
• vmonapi
• statsmonitor
• applmgmt
• sca (VMware Service Control Agent)
• vsphere-client
• cm
• vsphere-ui
• vmware-vpostgres (VMware Postgres)
• vpxd-svcs
• vapi-endpoint
• vpxd (VMware vCenter Server)
• sps (VMware vSphere Profile-Driven Storage Service)
• content-library
• vsm
• updatemgr
• pschealth
• vsan-health

Утилиту vmon-cli можно использовать для запуска и остановки этих сервисов в следующем формате:

/usr/lib/vmware-vmon/vmon-cli -r ServiceName

Например, чтобы перезагрузить vSphere Client, можно использовать команду:

/usr/lib/vmware-vmon/vmon-cli -r vsphere-client

Известный своими скриптами блоггер Luc Dekens (LucD) опубликовал интересный сценарий PowerCLI для виртуальной инфраструктуры VMware vSphere, который позволяет вычистить права доступа на объекты, для которых уже существуют права на уровне родительских объектов.

Например, у вас есть такая картина:

Соответственно, нам нужно почистить пермиссии в папке Test1131 для пользователя Local\test, чтобы разрешения остались только на уровне родительского объекта Test1 (там, как мы видим, установлена опция применения разрешений вниз к дочерним объектам).

Собственно, сам скрипт:

<#
.SYNOPSIS
  Find and remove redundant permissions on vSphere objects 
.DESCRIPTION
  The function will recursively scan the permissions on the
  inventory objects passed via the Entity parameter.
  Redundant permissions will be removed.
.NOTES
  Author:  Luc Dekens
.PARAMETER Entity
  One or more vSphere inventory objects from where the scan
  shall start
.EXAMPLE
  PS> Optimize-Permission -Entity Folder1 -WhatIf
.EXAMPLE
  PS> Optimize-Permission -Entity Folder?
.EXAMPLE
  PS> Get-Folder -Name Folder* | Optimize-Permission
#>
 
  [cmdletbinding(SupportsShouldProcess=$true)]
  param(
    [parameter(ValueFromPipeline)]
    [PSObject[]]$Entity
  )
 
  Begin{
    function Optimize-iVIPermission{
      [cmdletbinding(SupportsShouldProcess=$true)]
      param(
        [parameter(ValueFromPipeline)]
        [VMware.Vim.ManagedObjectReference]$Entity,
        [VMware.Vim.Permission[]]$Permission = $null
      )
 
      Process{
        $entityObj = Get-View -Id $Entity
        $removePermission = @()
        $newParentPermission = @()
        if($Permission){
          foreach($currentPermission in $entityObj.Permission){
            foreach($parentPermission in $Permission){
              if($parentPermission.Principal -eq $currentPermission.Principal -and
                 $parentPermission.RoleId -eq $currentPermission.RoleId){
                $removePermission += $currentPermission
                break
              }
              else{
                $newParentPermission += $currentPermission
              }
            }
          }
        }
        else{
          $newParentPermission += $entityObj.Permission
        }
        if($removePermission){
          if($pscmdlet.ShouldProcess("$($entityObj.Name)", "Cleaning up permissions")){
            $removePermission | %{
              $authMgr.RemoveEntityPermission($Entity,$_.Principal,$_.Group)
            }
          }
        }
        $Permission += $newParentPermission
       
        if($entityObj.ChildEntity){
            $entityObj.ChildEntity | Optimize-iVIPermission -Permission $Permission
        }
      }
    }
  }
 
  Process{
    foreach($entry in $Entity){
       if($entry -is [System.String]){
        $entry = Get-Inventory -Name $entry
       }
       Optimize-iVIPermission -Entity $entry.ExtensionData.MoRef
    }
  }
}

Скрипт работает так, что пробегается по дереву объектов, обнаруживает избыточные разрешения и удаляет их. У скрипта есть удобный параметр WhatIf, который выводит операции по очистке разрешений, которые как бы применяются к дочерним объектам, но на самом деле не применяет их:

Optimize-VIPermission -Entity Test1 -WhatIf

Результатом будет список объектов, где разрешения будут очищены, в данном случае, если посмотреть на пример выше, это будет папка Test1131:

Можно запустить скрипт и на 2 папки сразу:

Optimize-VIPermission -Entity Test1,Test2 -WhatIf

Результат будет таким (в папке Test22 также есть дублирующиеся разрешения):

Также можно использовать и конструкции с масками, например:

Get-Folder -Name Test? | Optimize-VIPermission -WhatIf

Теперь неплохо было бы, если бы кто-то написал GUI к этой штуке, а также добавил туда функции поиска и удаления произвольных разрешений в выбранных объектах.

Как знают администраторы VMware vSphere, с выходом каждой новой версии платформы увеличиваются и максимумы для ее компонентов. Многие из этих максимумов трудно достижимы на практике, поскольку еще нет серверов такой возможности (например, для запуска такого количества машин в производственной среде), но некоторые аспекты требуют того, чтобы лимиты параметров были увеличены (например, число vNIC на одну машину иногда для тестирования нужно больше).

Давайте взглянем на эволюцию максимумов VMware vSphere в таблицах ниже, где отображены параметры версии 5.5, 6.0 и 6.5:

Максимумы виртуальных машин

Максимумы вычислительных мощностей VMware ESXi

Максимумы хранилищ VMware ESXi

Максимумы сетевого взаимодействия VMware ESXi

С начала ноября мы не писали про тонкий клиент на базе HTML5 для управления виртуальной инфраструктурой - VMware vSphere Client (тогда он был версии 3.27). На днях компания VMware выпустила его версию 3.30, поэтому давайте рассмотрим новые возможности, которые появились в последних трех версиях клиента - VMware vSphere Client 3.28-3.30.

Итак, что нового:

• Просмотр имеющихся лицензий (Host/Cluster/функции Solutions) - пока работает в режиме Read-Only.
• Доступны детали лицензированных продуктов и их фичей.
• Детали лицензий сервера vCenter и хостов ESXi (Host License) - доступно в разделе Configure > Licensing.
• Проверки состояния vSphere Distributed Switch (vDS health checks).
• Настройка фильтрации трафика и правил его маркировки на уровне распределенных порт-групп.
• Экспорт и импорт распределенных виртуальных коммутаторов (vDS) и распределенных порт-групп.
• Настройка политик распределенных порт-групп внутри мастера создания новой порт-группы.
• Настройка CPU Identification Mask в разделе Advanced.
• Выбор паравиртуализованного сетевого адаптера PVRDMA для сети виртуальных машин.

Скачать последнюю версию VMware vSphere Client 3.30 можно по этой ссылке.

Cormac Hogan написал занимательный пост о об использовании дискового пространства в кластере VMware vSAN. Всех интересует - умеет ли vSAN возвращать дисковое пространство хранилищу при удалении файлов в гостевой ОС виртуальной машины? Ответ - пока нет, но над этим работают.

Cormac провел вот какой эксперимент: взял виртуальную машину в кластере vSAN с гостевой ОС Windows Server 2012 R2, у которой было 386.7 ГБ занятого места (сама ВМ была развернута на тонких дисках):

Затем он скопировал туда данные на 800 МБ, после чего увидел, что занятое место увеличилось до 388.37 ГБ, то есть выросло на 1,6 ГБ. Это логично, так как vSAN работал в режиме RAID-1 (зеркалированные VMDK-диски):

Далее он удалил только что скопированные файлы и убедился, что занятое дисковое пространство осталось тем же самым (то есть, в vSAN нет поддержки UNMAP/TRIM изнутри гостевой системы):

Между тем, он снова скопировал те же 800 МБ и к радости администраторов заметил, что дисковое пространство увеличилось лишь на 20 МБ (в совокупности на 40 МБ с учетом RAID-1).

То есть занятые после прошлого копирования блоки были использованы повторно:

Такая штука есть у Windows Server, но у Linux в файловой системе ext4 такой трюк не прокатит - все равно при повторном копировании блоки разместятся в другом месте, и пространство будет использовано повторно. Но это особенность файловой системы ext4, об этом подробно написано тут и тут. Для ФС ext3 и XFS это не актуально, там блоки тоже будут переиспользоваться.

Ну и помните, что описанное применимо только для удаления файлов изнутри гостевой ОС, если же вы удалите на хранилище vSAN виртуальную машину или другой объект - пространство сразу же вернется в общий пул хранения.

Мы часто пишем о встроенной утилите на хосте ESXi - esxtop, которая позволяет отслеживать все основные аспекты производительности хост-серверов и виртуальных машин (процессор, память, диски и сеть). Напомним, что наши последние посты о esxtop расположены тут, тут, тут, тут, тут и тут.

А недавно вышло весьма полезное образовательное видео "Using esxtop to Troubleshoot Performance Problems", в котором показано на практическом примере, как именно использовать esxtop для решения проблем производительности (хотя голос и весьма уныл):

Ну и напомним, что у esxtop есть графический интерфейс - это утилита VisualEsxtop.

Довольно давно мы уже рассказывали о механизме применения политик для хранилищ при развертывании виртуальных машин - VMware vSphere Storage Policy Based Management (SPBM). А недавно Кормак Хоган опубликовал интересную заметку, касающуюся возможности выбора политик SPBM конкретным пользователем во время развертывания новой виртуальной машины.

Прежде всего, в vSphere нет механизма назначения прав доступа пользователей на конкретную политику SPBM - все пользователи видят все политики. Но сам механизм разграничения прав существует - его можно реализовать на уровне прав доступа к хранилищам.

Например, пользователю ben мы даем доступ Read-only к хранилищу VVols1, то есть создавать виртуальные машины он на нем не может:

А на хранилище VVols2 делаем его администратором:

В итоге, при развертываниии виртуальной машины пользователь ben видит оба хранилища - VVols1 и VVols2 и все доступные политики хранилищ (комбобокс VM storage policy):

Однако, обратите внимание, что при выборе хранилища VVols1 в разделе Compatibility написано о том, что пользователь не имеет достаточных привилегий, чтобы создать машину на этом датасторе.

You do not hold the privilege to allocate space on the selected datastore

Между тем, кнопка Next активна. Но если нажать ее, мастер все равно дальше не пустит:

Вверху мы увидим:

Specify a valid location

Ну а если выбрать VVols2, то все проверки пройдут успешно, и пользователь сможет там создать виртуальную машину:

Бывает, что попытке развернуть виртуальную машину из шаблона (Template) вы получаете сообщение об ошибке "Customization of the guest operating system is not supported in this configuration":

Как правило, это происходит из-за того, что в машине не установлены VMware Tools. Просто сконвертируйте шаблон в ВМ, потом включите ее и установите тулзы, после чего конвертируйте машину опять в Template.

Также такая ситуация бывает, когда vCenter не поддерживает гостевую ОС виртуальной машины для кастомизации, либо когда развертывание происходит на NFS-хранилище, для которого не включена опция "no root squash".

С момента выхода последнего мажорного релиза платформы виртуализации VMware vSphere 6.5 мы много писали о шифровании виртуальных машин (и, кроме того, затрагивали тему производительности этого процесса), а также техниках шифрования кластеров vSAN (и некоторых особенностях этого). Сегодня мы поговорим о самом важном компоненте инфраструктуры шифрования vSphere - Key Management Service (KMS).

Прежде всего, KMS - это сервисы шифрования не только для виртуальных машин, но и любых других объектов ИТ-инфраструктуры. Поэтому KMS уже может быть в вашей организации, при этом он может не быть прикрученным к VMware vSphere. Вы можете использовать любой KMS-сервер, но VMware сертифицировала лишь следующие системы из списка (см. вот этот документ VMware):

Если же у вас другой KMS-провайдер, не расстраивайтесь - он, скорее всего, будет работать, если поддерживает протокол управления ключами KMIP 1.1.

Начать надо с вопросов доступности KMS-сервера. Как вы понимаете, это самый важный сервер в вашей инфраструктуре, важнее DNS или контроллера домена. Если у вас недоступен DNS, все тоже не работает, как и в случае с KMS, но если оказались недоступными данные хранилища KMS - это катастрофа для организации. И нет абсолютно никакого пути восстановить их. Совершенно никакого. Обо всем этом рассказывает видео ниже:

Таким образом, KMS становится бизнес-критичной точкой не только инфраструктуры, но и бизнеса в целом. И вопросы бэкапа и его доступности - это вопросы номер 1. Давайте посмотрим на несколько базовых понятий KMS:

• KMIP (Key Management Interoperability Protocol) - это стандарт, по которому клиент KMIP может общаться с серверами KMS. Каждый год он проходит серьезную проверку на конференции RSA.
• DEK (Data Encryption Key). Это ключ, который хост ESXi генерирует, когда требуется зашифровать виртуальную машину. Этот ключ используется также и для расшифровывания данных ВМ, он записан в VMX/VM Advanced settings в зашифрованном виде.
• KEK (Key Encryption Key). Это ключ, которым зашифрован DEK. KEK key ID также находится в VMX/VM Advanced settings.
• Key Manager Cluster/Alias - это коллекция адресов FQDN/IP всех реплицируемых между собой серверов KMS. Она также хранится вместе с зашифрованной машиной в VMX/VM Advanced settings, чтобы после ее включения можно было обратиться к нужному кластеру KMS, получить KEK для cервера vCenter, который разлочит ВМ.
• VM и vSAN encryption - это, на самом деле, с точки зрения реализации механизма шифрования одно и то же. То есть, для обоих типов шифрования используются одни и те же библиотеки, конфигурации и интерфейсы.

Когда мы говорим о кластере KMS - это всего лишь KMS-серверы, реплицирующие между собой хранилища ключей. Они не обеспечивают доступность друг друга, как, например, это делает VMware HA. Например, есть серверы KMS-A, KMS-B и KMS-C, в хранилищах которых при добавлении ключа новой ВМ он появляется мгновенно.

Если KMS-A недоступен как сервер, то сервер vCenter запрашивает ключи у хоста KMS-B. Если же KMS-A недоступен как сервис (то есть сервер работает, а служба KMS не отвечает), то vCenter ждет 60 секунд восстановления работоспособности сервиса и только потом переключается на KMS-B. Это поведение изменить нельзя.

Лучшие практики по использованию KMS таковы:

• По возможности нужно делегировать обязанности по поддержке инфраструктуры KMS отдельной команде (Security Team) или человеку.
• Не класть KMS-серверы в виртуальной машине в тот же кластер (например, vSAN), который также зашифрован. Иначе коробочка закроется (выключится кластер), а ключ от нее останется внутри нее же. То есть, необходимо держать хотя бы один из KMS-серверов за пределами такого домена отказа.
• Предыдущий пункт относится и к серверам vCenter и PSC. Чтобы они могли расшифровать другие сервера, они должны быть доступны в случае сбоя.

Теперь надо сказать о катастрофоустойчивости серверов KMS. Типичный кластер в рамках одной площадки выглядит так:

Но если на этой площадке будет авария, которая затронет все 3 сервера - бизнесу может настать конец. Поэтому в идеале надо использовать конфигурацию с двумя площадками:

Понятное дело, что у малого и среднего бизнеса резервных площадок, как правило, нет. В этом случае помочь может публичное облако Amazon AWS или Microsoft Azure. Чтобы поддерживать там одну резервную машину, много денег не нужно.

Ну и если вы используете конфигурацию с несколькими площадками, то обязательно нужно учитывать в конфигурации порядок обращения к серверам KMS в рамках площадки. Если на первой площадке находятся сервера KMS-A, KMS-B и KMS-C, а на второй - KMS-D, KMS-E и KMS-F, то в первом случае порядок должен быть A,B,C,D,E,F, а во втором - D,E,F,A,B,C.

Если на второй площадке вы будете использовать конфигурацию аналогичную первой, сервер vCenter может ходить по серверам другой площадки, которая может быть недоступна, а только обойдя все ее серверы, начнет использовать локальные KMS.

Мы много пишем о технологии Virtual Volumes (VVols), которая сравнительно недавно появилась в платформе виртуализации VMware vSphere. Совсем недавно мы писали о том, что будет в следующих версиях VVols, а сегодня давайте посмотрим на текущее положение дел.

Eric Siebert написал интересный пост о том, сколько компаний использует VVols сейчас в производственно среде. На данный момент VVols применяется примерно у 2% клиентов VMware, что весьма и весьма мало. Связано это, в первую очередь, с ограничениями технологии и небольшим количеством партнеров ее поддерживающих.

Между тем, подвижки в этом направлении уже есть. Вот какие факторы будут способствовать развитию VVols в ближайшем будущем (Эрик считает, что более половины всех пользователей vSphere будут применять эту технологию):

• Все больше клиентов переходят с vSphere 5.5 на vSphere 6.x, где VVols полностью поддерживаются.
• В vSphere 6.5 поддерживается функциональность аппаратной репликации томов VVol, что является очень важной и нужной фичей.
• Партнеры расширяют поддержку этой технологии в своих новых массивах.
• Клиенты все больше узнают о технологии, в том числе через этот пост:)

Если посмотреть на статистику использования VVols администраторами vSphere в различных компаниях, то во времени она выглядит так:

В принципе, прогресс за этот период выглядит неплохо (особенно в категории 100+), но в абсолютном выражении это, все-таки, очень мало. Ну и вот небольшой августовский отчет IDC про данную технологию - "VVols Provides Powerful Application-Aware Management for vSphere Environments".

Пара интересных роликов, вышедших на днях:

Рано или поздно каждый администратор приходит к тому, что ему необходимо каким-то образом сохранить, а потом и извлечь учётные данные. Причём это должно быть быстро, эффективно, удобно и самое главное безопасно. Ни один из известных мне способов не отвечал всем этим требованиям одновременно. Я стал искать и нашел свой способ, которым и хочу поделиться с вами. Это PowerCLI! Удивлены? Порой самое простое решение лежит на поверхности.

Наш читатель Стас обратил внимание на то, что в начале ноября компания VMware выпустила значительное обновление для шестой версии платформы виртуализации VMware vSphere 6.0. Были опубликованы апдейты и патчи для ESXi 6.0 - ESXi600-201711001.

В составе гипервизора и прочих компонентов были обновлены следующие пакеты ESXi 6.0:

• VMware_bootbank_esx-base_6.0.0-3.79.6921384
• VMware_bootbank_vsan_6.0.0-3.79.6766495
• VMware_bootbank_vsanhealth_6.0.0-3000000.3.0.3.79.6769065
• VMware_bootbank_esx-dvfilter-generic-fastpath_6.0.0-3.79.6921384
• VMware_bootbank_misc-drivers_6.0.0-3.79.6921384
• VMware_bootbank_ipmi-ipmi-devintf_39.1-5vmw.600.3.79.6921384
• VMware_bootbank_ipmi-ipmi-msghandler_39.1-5vmw.600.3.79.6921384
• VMware_locker_tools-light_6.0.0-3.76.6856897

Обновления коснулись новых возможностей, подсистемы безопасности и исправлений наиболее серьезных ошибок. Чтобы скачать апдейт, нужно пойти на VMware Patch Portal, выбрать ESXi 6.0 и ввести там номер билда (6921384).

Правильно устанавливать обновление нужно следующими командами (если, конечно, на хосте есть интернет):

esxcli network firewall ruleset set -e true -r httpClient

esxcli software profile update -p ESXi-6.0.0-20171104001-standard -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

esxcli network firewall ruleset set -e false -r httpClient

Кроме того, на днях также было выпущено обновление VMware vCenter 6.0 Update 3c. Там появилось три основных новых улучшения:

• Включенная поддержка SMB2 для виртуального модуля vCenter Server Appliance 6.0 Update 3c, чтобы избежать уязвимости протокола SMB1.
• Совместимость с решениями VMware vSphere Replication 6.1.2.1 и VMware Site Recovery Manager 6.1.2.1.
• Улучшения кластеров VMware Storage DRS.

Получить больше информации об обновлении VMware vCenter 6.0 Update 3c можно по этим ссылкам:

• VMware-VIMPatch-6.0.0-7037384-20171101.iso
• VMware-vCenter-Server-Appliance-6.0.0.30300-7037817-patch-TP.iso
• VMware-vCenter-Server-Appliance-6.0.0.30300-7037817-patch-FP.iso

Скачать vCenter 6.0 u3c можно по этой ссылке.

В середине октября мы писали о новых возможностях VMware vSphere Client версий 3.22-3.24. Напомним, что этот тонкий клиент на основе технологии HTML5 скоро заменит собой устаревающий Web Client на основе Adobe Flex. За последние 3 недели компания VMware успела выпустить целых три версии vSphere Client 3.25, 3.26 и 3.27.

Давайте посмотрим на новые возможности этих версий клиента:

• Всплывающее окно файлового менеджера Datastore File browser. Также была улучшена его производительность и информативность окна загрузки (показаны файлы в очереди и общий объем загружаемого контента).
• Добавление лицензии для хостов vSphere и возможность задания ее имени в рабочем процессе добавления. Также можно ее переименовывать и удалять.
• Просмотр свойств лицензий (лицензированных продуктов и технологий на хостах).
• Просмотр ассетов лицензии vCenter (в режиме read-only).
• Редактирование свойств и политик для распределенных портов vDS.
• Можно развернуть ВМ из шаблона, выбрав мастер создания новой ВМ, далее Deploy from template > вкладка Data center.
• Операция Rescan теперь выполняется параллельно на уровне датацентра и кластера.
• Группами Replication groups можно управлять через действие Edit VM Storage Policy.

Скачать VMware vSphere Client 3.27 можно по этой ссылке.

Как многие из вас знают, в конце лета и начале осени прошли главные конференции по виртуализации этого года - VMworld 2017 и VMworld Europe 2017. Об основных анонсах мероприятий мы писали по этой ссылке, но в рамках этих ивентов было еще столько всего, что обо всем, конечно же, не напишешь.

Специально для тех, кто хочет узнать тонкости всех докладов, которые были представлены на конференциях, компания VMware создала репозиторий на GitHub, где содержатся вообще все ссылки на сессии, многие из которых дадут много новой информации и технических деталей о продуктах и технологиях виртуализации от VMware:

Сессии доступны как в виде роликов на Youtube, так и виде PDF-документов.

Ну а вот список самых популярных сессий (топ-10 по числу просмотров на Youtube):

• [SER1143BU] - A Deep Dive into vSphere 6.5 Core Storage Features and Functionality [NET1152BU] - Introduction to VMware NSX
• [SER1534BUR] - vSphere Performance Troubleshooting and Root Cause Analysis
• [VIRT1309BU] - Monster VMs (Database Virtualization) with vSphere 6.5: Doing IT Right
• [NET1345BU] - NSX in Small Data Centers for Small and Medium Businesses
• [SER2724BU] - Extreme Performance Series: Performance Best Practices
• [VIRT1430BU] - Performance Tuning and Monitoring for Virtualized Database Servers
• [ADV1587BU] - NSX + VMware Horizon: A Security Architecture for Delivering Desktops and Applications with VMware
• [SER2355BU] - Best Practices for All-Flash Arrays with VMware vSphere
• [SER2965BU] - Advanced Troubleshooting of ESXi Server 6.x for vSphere Gurus
• [SER2077BU] - Achieve Maximum vSphere Stability with PowerCLI Assisted Documentation: From Buildout to Daily Administration

Оказывается, у VMware есть интересная утилита с открытым исходным кодом - Weathervane. Это бенчмаркинг-тул, предназначенный для запуска тестов производительности в виртуальных средах VMware vSphere (как онпремизных, так и облачных), с учетом симуляции реальной нагрузки различных приложений. Утилита доступна в открытом репозитории на GitHub.

Weathervane позволяет, например, снять метрики с двух различных окружений или его конфигураций, что позволит выбрать наиболее производительную конфигурацию виртуального окружения и выставить самые эффективные настройки виртуальной среды. Также с помощью Weathervane компания VMware сама делает различные тесты, к примеру, вот документ о производительности контейнеров Docker в виртуальной среде VMware vSphere - "Performance of enterprise web applications in Docker containers on VMware vSphere 6.5".

Weathervane имеет возможности по развертыванию нескольких независимых экземпляров приложения и его отдельных сервисов в контейнерах Docker, запуску различных нагрузок и конфигурации параметров их исполнения для измерения необходимых метрик производительности. То есть, это утилита для бенчмаркинга производительности именно на уровне приложений.

Weathervane состоит из трех основных компонентов:

• Приложение (Auction application), которое развертывается в среде тестирования.
• Драйвер рабочей нагрузки (Workload driver), который выдает реалистичную нагрузку для приложения с учетом заданных параметров тестирования.
• Компонент исполнения (Run harness), который автоматизирует процесс исполнения тестовых запусков приложения и собирает результаты, логи и, собственно, данные о производительности.

Также в составе Weathervane есть Supporting tools, которые включают в себя скрипты для настройки экземпляра операционной системы со всем необходимым для запуска утилиты, создания образов Docker и подготовки приложения для запуска в среде тестирования.

При проведении тестирования вы можете изменять следующие параметры:

• Число экземпляров на уровне каждого сервиса. Например, может быть любое число балансировщиков нагрузки, серверов приложений или узлов веб-серверов. Это позволяет создавать конфигурации любого масштаба.
• Число ярусов целевой архитектуры. Например, вы можете не использовать некоторые компоненты, такие как балансировщики и веб-сервера, если вам нужно протестировать небольшую по объему среду.
• Вариант развертывания среды. Например, Weathervane сейчас поддерживает PostgreSQL и MySQL в качестве транзакционной БД, а также Apache Httpd и Nginx в качестве веб-серверов. Ну и надо помнить, что это open source проект, а значит вы сами можете расширять его.
• Конфигурацию сервисов. В настроечном файле можно изменять параметры для каждого из ярусов, которые будут применяться компонентом run harness перед началом каждого прогона бенчмарка.

Для больших инфраструктур и тестовых сред Enterprise-приложений Weathervane предоставляет следующие средства:

• Вы можете запускать экземпляры приложения напрямую в ОС, неважно в физической или виртуальной машине, а также в контейнерах Docker (это позволит сравнить эти варианты развертывания между собой по производительности). Как мы писали выше, Weathervane содержит скрипты для создания образов Docker для всех сервисов приложений.
• Вы можете задать пользовательскую нагрузку для экземпляров приложения, которая позволит оценить поведение приложения при критических нагрузках, циклических паттернах нагрузки и поведение сервиса в плане эластичности.
• Поддерживается изменение числа экземпляров приложения прямо во время исполнения теста, что позволит снять метрики, относящиеся к эластичности сервиса (то есть его способности динамически выделять и освобождать ресурсы при изменении нагрузки). В будущем будет также добавлен мониторинг поведения среды в реальном времени, чтобы оперативно оценивать эластичность и инертность сервиса по отношению к нагрузке.

Руководство по использованию VMware Weathervane доступно по этой ссылке. Ну а сам проект Weathervane на GitHub доступен тут: https://github.com/vmware/weathervane.

На сайте VMware Labs появилась очередная интересная утилита - Blockchain on vSphere. О блокчейне сейчас говорят все, но немногие знают, что эти решения уже используются не только в криптовалютах, но и в самых различных областях - медицине, экономике, а также есть даже такие необычные кейсы, как пресечение торговли людьми и отслеживание сбыта "кровавых" алмазов.

Компания VMware также не осталась в стороне и запустила вспомогательный проект Blockchain on vSphere, который помогает администраторам развернуть блокчейн-платформу для разработчиков на основе гипервизора ESXi. Эта утилита представляет собой средство развертывание решения Hyperledger Fabric v1.0 на платформе vSphere.

Hyperledger - это open source проект сообщества Linux Foundation и основа Hyperledger Fabric, которая предоставляет разработчикам возможности сделать свой блокчейн-проект с необходимой бизнес логикой. Blockchain on vSphere позволяет просто развернуть узлы кластера Hyperledger Fabric (Pods), так как это довольно сложная процедура, которую и упрощает VMware.

Целевая архитектура развернутого решения выглядит следующим образом:

Hyperledger Fabric - это распределенная система на основе технологии контейнеров. Она может быть развернута на платформе, которая поддерживает стандарт OCI (VMware его поддерживает). Решение Kubernetes используется для управления контейнерами Hyperledger Fabric.

Чтобы понять, как именно Blockchain on vSphere облегчает построение блокчейн-платформы на основе vSphere, посмотрите видео ниже:

Также при скачивании Blockchain on vSphere по этой ссылке, в комбо-боксе над кнопкой Download можно выбрать whitepaper о продукте, в котором подробно описывается весь процесс развертывания Hyperledger Fabric с помощью BoV.

Как часто вам приходится увеличивать логические диски внутри гостевых ОС ВМ? Довольно часто, не так ли? Вам надо сначала найти вашу ВМ в vSphere Client, потом кликнуть Edit Settings и перво-наперво увеличить виртуальный диск ВМ. После вы должны будете открыть RDP к вашей ВМ, затем открыть Disk Management, выбрать Rescan Disks из контекстного меню и только после этого ещё один правый клик на нужном вам логическом диске и вот сейчас выбрать Extend Volume...

Недавно компания VMware выпустила интересный документ VMware vSphere APIs for I/O Filtering (VAIO), в котором описываются основные принципы работы данной технологии. Ниже мы расскажем о них вкратце, а также затронем тему того, каким образом можно использовать VAIO в производственной среде.

VAIO - это технология и API, которые позволяют получать прямой доступ к потоку ввода-вывода (I/O Stream) гостевой ОС виртуальной машины. Механизм VAIO уже сейчас способствует созданию партнерских продуктов для решения самых разнообразных задач (например, кэширование write-back и write-through). VAIO основан на механике Storage Policy Based Management (SPBM), которая предназначена для управления правилами хранения виртуальных машин и их работой с хранилищами.

Техническая реализация данного механизма подразумевает использование драйвера VAIO (filter driver), который устанавливается на хосте VMware ESXi как пакет VIB и не требует установки никакого специального ПО в гостевой ОС виртуальной машины.

Посмотрим на эту картинку, на которой изображен путь данных от виртуальной машины к физическому устройству хранения. На ней представлены 2 компонента, относящиеся к VAIO. Первый - это VAIO фреймворк, работающий на уровне ядра VMkernel и определяющий действующую политику фильтра. Второй - это IO Filter, представляющий собой программное обеспечение, работающее на уровне пользовательской среды исполнения (User World) сервера ESXi. Этот драйвер фильтра исполняет свою функцию (например, кэширование данных или их репликация), после чего передает их на физическое устройство хранения для записи.

Такая архитектура позволяет драйверу IO-фильтра получать доступ к потоку ввода-вывода, не сильно не влияя на производительность исполнения SCSI-команд. Еще одна особенность IO-фильтра - это возможность иметь доступ к потоку ввода-вывода как в сторону записи (от ОС к хранилищу), так и в обратную сторону (квитанции о прохождении команд). Это полезно, например, при использовании IO-фильтра для технологии репликации, где очень важно получать квитанции о записи данных на диск.

Кстати, SCSI-команды попадают к IO-фильтру сразу после того, как они проходят слой эмуляции SCSI (он же vSCSI), что позволяет использовать VAIO для любых типов хранилищ - VMFS, NFS, SCSI и vSAN. Ну а перехват команд IO-фильтром перед их отсылкой в сетевой стек к хранилищу позволяет обеспечить целостность данных и безопасность.

Еще, если внимательно посмотреть на архитектуру прохождения потока ввода-вывода, можно заметить, что драйвер IO-фильтра работает на уровне User World, а значит в целом не влияет на стабильность работы сервера ESXi. Даже если он вдруг прекратит свою работу, основной стек прохождения SCSI-команд, расположенный в ядре, продолжит работать в нормальном режиме.

Работает IO Filter на уровне отдельных VMDK-дисков конкретных ВМ, что открывает широкие возможности для механизма политик Storage Policy Based Management (SPBM) и применения их к отдельным виртуальным машинам и сервисам.

Все вышеперечисленное позволяет применять VMware VAIO при решении следующих типов задач:

• Encryption – стороннее ПО за счет использования механизма VAIO может на лету шифровать и расшифровывать поток данных от виртуальной машины. Таким образом на хранилище будут помещаться уже шифрованные данные. Гранулярность работы VAIO позволяет обслуживать данные, идущие даже не от всей виртуальной машины, а только от одного приложения.
• De-duplication - этот механизм уже использует решение VMware Virtual SAN. В реальном времени можно дедуплицировать данные, проходящие через драйвер и в таком виде уже класть на хранилище в целях экономии дискового пространства. Эта техника доступна и партнерам VMware.
• Tiering - данные различной степени важности, критичности или классифицированные по другим критериям теперь можно класть на хранилища с разными характеристиками производительности и доступности (ярусы). Механизм VAIO тут поможет проанализировать характер данных и определить конечное их место назначения.
• Analytics - теперь можно анализировать непосредственно поток данных от конкретной виртуальной машины и на основе этого строить множество различных решений, включая решения по кэшированию (например, такой продукт как PrimaryIO, который можно напрямую подключить к гипервизору). Затем можно, например, искать в трафике данные определенных приложений, либо, использовать механизм write-back кэширования.

Технология VAIO работает, начиная с VMware vSphere 6.0 Update 1, поддерживает горячую миграцию vMotion (VAIO должна быть доступна на целевом хосте) и кластеры VMware DRS (должна быть доступна на всех хостах).

Давайте теперь посмотрим, как VAIO работает на практике на одном из примеров. Чтобы начать работать с VAIO, вам нужно установить IO Filter в виде VIB-пакета, который реализует функциональную составляющую партнерского продукта для VMware vSphere.

Как правило, вместе с фильтром идет и политика SPBM (аналогичная тем, которые есть для vSAN или VVols, например), которую можно назначать виртуальным машинам на уровне виртуальных дисков VMDK.

Эту политику можно назначить при создании виртуальной машины в разделе Select Storage (в данном случае это политика кэширования на SSD):

Пример политики, идущей вместе с фильтром, как правило включает в себя Common Rule - правила, которые реализуют Data Services (то есть основной функционал фильтра) и определяются через компоненты Storage Policy Components (путем добавления компонентов в разделе Common Rules).

Например, в данном случае это тип кэширования Write Through или Write Back, который мы задаем в разделе Common Rules при создании новой политики хранения:

По умолчанию эти компоненты устанавливаются вместе со встроенными фильтрами vSphere и другими продуктами, которые пополняют набор IO-фильтров, а соответственно и компонентов по мере их установки. За счет использования Storage Policy Components возможности IO-фильтров могут быть включены в любую из уже настроенных политик VM Storage Policies.

Это очень удобно, поскольку на данный момент виртуальная машина или VMDK-диск могут иметь только одну примененную к ним политику хранения, но к ним можно добавить компоненты от разных фильтров.

Ну а сами IO-фильтры от разных производителей вы можете найти в VMware Compatibility Guide по этому адресу - https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vaio.

Как видно из картинки, на данный момент не так много партнеров используют технологию VAIO для своих продуктов, а категорий решений всего две - репликация и кэширование. Но VMware активно работает в этом направлении, и в скором времени, возможно, мы увидим еще несколько продуктов, реализующих функционал IO-фильтров для решения новых задач.

Один из блоггеров, пишущих о платформе VMware vSphere (у него есть кстати симулятор экзамена VCDX), выложил на GitHub интересный документ, который может оказаться полезным администраторам больших виртуальных инфраструктур и сотрудникам системных интеграторов - vTestPlans.

Это документ, доступный в форматах Microsoft Word и PDF, представляет собой план тестирования виртуальной инфраструктуры VMware vSphere. Да, пока он еще весьма небольшой и очень приблизительный, но автор уверяет, что будет развивать и расширять его, в том числе за счет помощи от участников сообщества VMware.

Штука эта на самом деле полезная, когда вы в какой-нибудь компании внедряете VMware vSphere и хотите проверить работоспособность программно-аппаратного комплекса в целом после развертывания.

На днях некоторые пользователи VMware vSphere заметили, что их браузер Google Chrome крашится при попытке доступа через VMware vSphere Web Client на базе технологии Adobe Flex к серверу vCenter. Баг обнаружил William Lam и другие пользователи vSphere.

В этом случае Хром вываливается вот с такой ошибкой:

Shockwave Flash has crashed

При этом ни перезапуск хрома, ни перезапуск системы не помогает избавиться от ошибки.

Вся фишка в том, что Google выпустила обновление библиотеки Flash (27.0.0.170) вместе с последним обновлением браузера Chrome (61.0.3163.100), которое имеет ошибки при работе с флешем, причем не только для продуктов VMware. Одним из временных решений проблемы было бы использование браузера Firefox, но и там используется такая же библиотека Flash.

Ну а чтобы вылечить Google Chrome нужно сделать вот что:

1. Найти старую библиотеку pepperflashplayer.dll для Google Chrome (например, для Windows она выложена здесь) и положить ее в папку 27.0.0.170 вашей директории Chrome.

Находится эта папка вот тут:

• Windows - %LocalAppData%\Google\Chrome\User Data\PepperFlash
• Mac OS - ~/Library/Application Support/Google/Chrome/PepperFlash

2. Отключить функции автоматического обновления Google Chrome. Для этого в ключе реестра:

HKLM\SOFTWARE\Policies\Google\Update\AutoUpdateCheckPeriodMinutes

нужно выставить значение 0. После этого Chrome должен заработать с vSphere Web Client:

На Mac OS, кстати, старая версия библиотеки сохраняется в папке 27.0.0.159, поэтому вы просто можете скопировать ее в новую папку 27.0.0.170 и залогиниться в vSphere Web Client.

Баг этот очень неприятный, но в этот раз VMware не виновата. Накосячили в Гугл и Адоби. Флеш умирает сам:)

Следить за обновлениями о баге можно по этой ссылке.

В сентябре мы писали о новых возможностях тонкого клиента vSphere Client 3.21, предназначенного для управления виртуальной инфраструктурой через браузер на базе технологии HTML5. За прошедший месяц вышли обновленные версии VMware vSphere Client 3.22, 3.23 и 3.24, о новых возможностях которых мы расскажем ниже.

Итак, что нового появилось в vSphere Client (на картинке выше, кстати, скрин кастомизации ОС):

• Возможность кастомизации всех сетевых настроек, включая шлюз по умолчанию, при применении спецификации кастомизации гостевой ОС виртуальной машины (при клонировании или кастомизации существующей ВМ).
• Добавление контроллера NVMe для новой или существующей ВМ.
• Улучшенное представление просмотра деталей о совместимости в мастере развертываниия новой ВМ.
• Возможность загрузки папки из файлового браузера.
• Группы DRS могут быть отфильтрованы по их составляющим хостам.
• В портлете VM Storage Policy отображаются Replication groups.
• Можно посмотреть список установленных VIB-пакетов (на vSphere 6.5).
• Редактирование информации о видеокарте для виртуальной машины.
• Пофикшено множество багов, в том числе касающихся снапшотов.

Скачать VMware vSphere Client 3.24 можно по этой ссылке.

Как пишут многие, в последнее время с виртуальным модулем VMware vCenter Server Appliance (vCSA) часто случаются проблемы. Например, вот такая ошибка появляется время от времени:

503 Service Unavailable (Failed to connect to endpoint: [N7Vmacore4Http20NamedPipeServiceSpecE:0x0000559b1531ef80] _serverNamespace = 
/ action = Allow _pipeName =/var/run/vmware/vpxd-webserver-pipe)

Как пишет Anthony Spiteri, зачастую эта ошибка связана с тем, что Linux-система, на базе которой работает vCSA (а именно Photon OS в vCSA 6.5), пока еще имеет достаточно ненадежную реализацию стека работы с хранилищами (в отличие от того, который есть в Windows). Поэтому при некоторых неполадках со стораджем или появлении высокой задержки (latency) сервер vCSA может "выпадать".

Ведь vCSA 6.5 имеет аж 12 файлов виртуальных дисков VMDK (раньше их было два), с которыми что-нибудь да может иногда случиться. Один из вариантов решения - проверить диски утилитой e2fsck, которая может проблем в случае 503 ошибки. Также проблема может таиться в USB-устройствах, и тогда вам поможет вот эта статья. А еще можно заглянуть вот сюда.

Может еще помочь выполнение следующих команд в консоли vCSA для перезапуска vSphere Web Client (надо будет подождать 15 минут):

service-control --stop vsphere-client

service-control --start vsphere-client

Ну и не забудьте заглянуть в эту ветку форумов VMware.

Интересно, что совсем недавно компания VMware анонсировала ежемесячные обновления vCSA, что может постепенно уменьшить имеющиеся проблемы. Но пока надежность vCenter для Windows остается более проверенной штукой (по крайней мере, в плане хранилищ), поэтому пока все вокруг топят за vCSA, подумайте нужно ли именно сейчас на него переезжать.